-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow auto-dispose of factory generated services #179
Conversation
Nice find @eXpl0it3r ! I don't think this should be an opt it. The intent of the library is to match Microsoft.Extensions.DependencyInjection in behavior and MEDI disposes factory results by-default. I suspect most users are unintentionally leaking memory because of this issue. Do you mind changing the PR so the behavior is unconditional? |
@pakrym For sure I can work on making this on by default. I would love to keep the ability to opt out of dispose here. Currently I'm not aware of a possibility to let jab register a class with multiple interfaces. Therefore I use the factory approach to circumvent this. However in doing so I would end up disposing an instance multiple times which is why I would prefer to keep the ability for the user to control whether jab owns the instance or not. |
My bad @sensslen! Thank you for you contribution! Do your classes throw when disposed multiple times? The general recommendation is that multiple disposal should be safe:
|
No, they don't - It just feels like wasteful to keep these instances even though their disposal has already been taken care of.... |
PR updated |
Thank you! |
This PR adds the capability to auto-dispose factory generated services. I found that there was a broken test that indicates that disposing factory generated services was indended but was not properly implemented (the test was flawed). This PR adds a flag that allows users to opt into automatic dispose of factory generated services.
This functionality could be improved by erroring out when the AutoDispose flag is used other than for factory generated services.
This PR also updates the CI/CD pipeline to work
This PR drops netcoreapp3.1, as I got test failures with this framework that has long been deprecated by microsoft and thus it seemed useless to investigate in the reason for the failures.
Fixes #178